\subsection{Description de l'entreprise}

Pour commencer, nous allons étudier l'entreprise ayant lancé ce projet, Atonce Technologies. Il est important de bien la situer dasn son environnement pour mieux comprendre les enjeux de ce stage.
\subsubsection{Entreprise et historique}

La société Atonce Technologies est une SARL spécialisée dans la conception, réalisation et commercialisation de logiciels Middleware. Elle fait commerce de logiciel de hautes technologies pour l'industrie de développement de jeux vidéo sur console.

\paragraph{}Atonce fut créée en octobre 2004 par Gerald Gainant. Elle a réalisé Neova-Core Engine qui constitue son produit phare.
Ce Middleware destiné aux développeurs de jeux vidéos sur Wii apporte tous les services liés au matériel : affichage 3D et 2D, sons, entrées et sorties, streaming, gestion mémoire, gestion de la Wiimote, etc.

Neova respecte les chaînes de production existantes, apporte une grande facilité de développement pour les jeux multi-plateformes, un seul code étant compilé sur toutes les plateformes cibles.

\paragraph{}Il supporte les plateformes suivantes : Nintendo Wii, Sony PlayStation 2, Sony PlayStation Portable, DirectX.

Neova remplace avantageusement des solutions middleware de générations précédentes avec des tarifs extrêmement compétitifs.

Atonce Technologies développe aussi des jeux vidéos pour la Wii. En effet, cette entreprise développa le jeu vidéo \textit{Bienvenue chez les Ch'tis} courant 2008.

\subsubsection{Personnel}

Atonce Technologies est une PME avec peu d'employés. Une grande partie de son activité est assuré par son PDG : Gerald Gainant. Durant ce stage, nous étions quatre stagiaires et deux employés.

Un autre binôme provenant également de l'université Bordeaux 1, Michaël fery et Stéphane Morry, se sont focalisés sur la détection de mouvement de la Wiimote.

Les autes employés et le PDG, Gerald Gainant, travaillaient sur la réalisation du nouveau framework Sugar et des outils y afférants.

\newpage

\subsection{Description des méthodes de travail}

Dans cette partie, nous allons nous focaliser sur les méthodes de développement qui furent employées chez Atonce Technologies.

\subsubsection{Description de la méthode SCRUM}

Voici tout d'abord la description de SCRUM, la méthode de développement imposée dès le commencement du stage.

\paragraph{}Tout d'abord SCRUM est une méthode agile, deplus les développeurs sont censés être très proches du client. Ensuite, elle s'axe sur des \textit{sprints} allant d'une durée d'une semaine dans le meilleur des cas, à un mois au maximum.
Chaque \textit{sprint} doit donner une version fonctionnelle du projet. Ce sont des versions non finalisés, et donc incomplêtes. Cependant dès le début du développement, l'application doit s'exécuter.

\paragraph{}Néanmoins, entre les \textit{sprints}, il faut définir les taches à effectuer. L'approche du projet dans SCRUM est un peu particullière. En effet, cela s'organise sous la forme d'un tableau où l'on appose des post-its. Ils sont découpés en trois catégories que l'on répartie verticalement. Tout en haut du tableau, nous plaçons les objectifs. Ils sont extrêmements généraux et tiennent en une phrase. Par exemple, dans le cadre du projet, les objectifs étaient : \og Disposer d'une documentation en Flash \fg, \og Disposer d'une documentation lisible\fg.

\paragraph{}Ensuite, les objectifs se répartissent en plusieurs \textit{features}. Les \textit{features} étaient des qualificatifs sur les objectifs. Par exemple : \og Je veux que l'application soit robuste\fg, \og Je veux que l'application soit réactive\fg .
Enfin, les features se divisaient en plusieurs \textit{user stories} qui représentaient les besoins que demanderaient différents acteurs. Par exemple, si on se plaçait du côté d'un utilisateur, il pouvait exprimer certains besoins : \og En temps qu'utilisateur, je veux comprendre rapidement le code documenté\fg. Mais il faut tenir compte aussi d'autres acteurs, par exemple : \og En temps que rédacteur, je veux générer ma documentation facilement\fg.
Ensuite, au dos des post-it contenant les \textit{user stories}, on y inscrivait la liste des tâches nécessaires à leur réalisation.
Ces tâches s'apparentaient à celles rencontrées dans la méthode XP. Elles sont censées être très courtes. Les \textit{user stories} devaient ensuite disposer d'un indice de vélocité. Plutôt que donner un indice absolu qui indique une durée en temps, cet indice est censé situer les \textit{stories} les unes par rapport aux autres.

\paragraph{}Cette méthode dispose aussi de différents postes, dont un SCRUM Master, l'équivalant du tracker de la méthode XP, qui se charge de faire bien respecter l'utilisation de SCRUM.
Au final, lorsqu'un \textit{sprint} est terminé, l'équipe doit choisir de nouvelles \textit{user stories} à réaliser.
C'est donc ainsi que doit s'effectuer un projet SCRUM.



\subsubsection{Méthodes réellement employées}
L'inconvénient majeur était que nous étions seulement deux personnes sur ce projet, novices tout deux en SCRUM, car étant stagiaires de l'université de Bordeaux 1. Nous étions donc extrêmement inexpérimentés sur l'emploi de cette méthode. Un autre inconvénient était l'absence de SCRUM Master. En effet, Gérald Gainant, le maître de stage, tenait partiellement ce rôle, mais tenait aussi un rôle proche de celui de client. Sans oublier qu'il avait son propre travail à côté. Nous n'avions donc pas un suivi suffisant de notre travail sur SCRUM.

\paragraph{}D'autres problèmes sont apparus assez rapidement. En effet, nous avons eu pour prérogative de travailler en binôme sur ce projet. Nous étions donc un seul binôme à travailler sur l'ensemble du projet en utilisant SCRUM. Il nous est apparu assez vite que cet méthode n'était pas très adaptée dans ce cas là. Le binômage non plus, peut-être. Néanmoins, pour le cas du binômage, cela pouvait se réveller être une aide précieuse car nous découvrions tout deux le langage Actionscript. Donc nous nous entraidions l'un l'autre dès que l'un comprenait quelque chose.

\paragraph{}Ensuite, nous avons préféré employer une méthode un peu différente lors de la réalisation des \textit{user stories}. Nous avons créé une multitude de scénarios afin de mieux cibler les situations auxquelles pourrait être confronté chaque acteur. Cette technique a permis dès le début de trouver beaucoup d'idées. La compréhension des problèmes que se posent les différents acteurs fut réellement facilitée par le binômage.

\paragraph{}Il est vrai aussi que pour l'ensemble des phases de recherches, le fait d'être à deux sur un même poste a pu ralentir l'avancé du projet. Néanmoins, le stade du binomage ne dura pas l'intégralité du stage. Il ne se déroulla que le temps de bien définir les normes et s'approprier les outils de développement. Un binômage bien employé revient certainement à un gain de temps, mais il faut l'employer avec parcimonie. Le fait d'avoir brisé le binôme après un certain temps fut probablement une très bonne chose. Une augmentation significative du code fourni se fit sentir après cette séparation, mais le travail total réalisé aurait très certainement était infèrieur en qualité et en quantité sans la phase initiale en binôme.

\newpage

\subsection{Cadre du projet dans l'entreprise}

\subsubsection{Explications sur le langage SIDL}

Atonce s'est récemment lancé dans un nouveau framework visant à remplacer leur ancien produit Neova. En effet, Gerald Gainant, PDG d'Atonce, a décidé de créer une nouvelle mouture qui se nomera Sugar.
Les caractéristiques précises de ce nouveau framework ne sont pas encore connues, nénamoins la particularité principale de ce nouvel outil sera le SIDL. 

\paragraph{}Le SIDL est le nom choisi par Atonce pour désigner un méta langage permettant de générer du code C++. Comme beaucoup l'on remarqué en codant en C++, la syntaxe peut paraître légèrement lourde pour certains. L'ennui principal est qu'il est nécessaire de placer beaucoup de code n'ayant pas toujours une forte utilité pour le programmeur. Ainsi, la compréhension du code peut en être troublée. De plus, avant de réellement pouvoir se pencher sur l'architecture ou l'algorithmique, il est parfois nécessaire de réaliser beaucoup de code. Atonce ayant jugé que cette syntaxe était trop lourde, le langage SIDL fut donc créé afin de définir directement des interfaces et des implémentations, un peu comme pour le langage Java.


\paragraph{}Dans le langage SIDL, cela se traduit assez simplement, en effet, le programmeur spécifie une interface contenant un certain nombre de fonctions et ayant des implémentations en héritant afin de générer le code C++ des fichiers \textit{.h} et des fichiers sources correctements remplis.
Voici un exemple de code SIDL :


\begin{center}

\begin{figure}[h!]

 \includegraphics[scale=0.6]{Images/Exemple-SIDL.png}
 \caption{Exemple SIDL}
 \label{exemple-sidl}
 
\end{figure}

\end{center}

Les fichiers C++ générés peuvent ensuite être complétés. En effet, les fonctions sont toutes vides. Néanmoins, il faut préciser que le code généré est censé compiler sans erreurs.
Suivant les types de retours spécifiés aux fonctions SIDL, les fonctions C++ générées coïncideront. Par exemple, s'il est spécifié qu'une fonction renvoie un \textit{int}, alors la fonction retournera l'entier 0.

Le langage SIDL offre une propriété supplémentaire au niveau du code C++ généré. En effet, Atonce a décidé qu'il serait pertinent de briser les liens d'héritage entre les classes. Cela peut sembler déconcertant, nous allons donc tenter de bien expliquer ce principe.
Par exemple, une interface et une implémentation peuvent être définies en SIDL, avec l'implémentation héritant de l'interface. Naturellement, Sugar générera une classe C++ qui représentera l'implémentation et une classe virtuelle pour représenter l'interface SIDL. Cela impliquera que la classe implémentera les fonctions définies par l'interface C++, mais sans en hériter. De cette façon, la classe et l'interface en C++ sont indépendantes.

\paragraph{}Le langage SIDL ne s'arrête pas là. A terme, Atonce souhaiterait que le code généré ne soit pas uniquement du C++. En effet, générer les idées du langage SIDL avec du code est possible dans d'autres langages. Il serait donc faisable de choisir le langage dans lequel l'utilisateur souhaite générer le code.
Nous n'approfondirons pas la mécanique derrière le langage SIDL car ce serait trop s'écarter du sujet. Rappelons que les trois principaux éléments SIDL documentables sont les interfaces, les implémentations, et les fonctions.
Atonce compte d'ailleurs munir ce langage d'une palette d'outils afin de le promouvoir le plus possible.

\subsubsection{Outils périphériques}

Comme cela fut énoncé légèrement plus haut, quelques outils sont déja en préparation afin de rendre le langage SIDL et donc le framework Sugar, plus attirant pour de futurs clients.

\paragraph{}Pour être plus convaincant, SIDL se doit de diposer d'un IDE\footnote{Integrated Developpement Environment} afin de faciliter le travail des programmeurs qui vont utiliser ce langage sur le long terme.
Atonce a donc décidé de créer un plug-in pour l'IDE Visual Studio, créé par Microsoft. Il n'est encore qu'au stade de développement, cela impliquant qu'aucune information ne puisse être donnée sur lui.

\paragraph{}Mais Atonce compte poursuivre son développement. En effet, un des outils principaux servant en périphérique du langage SIDL sera le générateur de documentation. Ce projet prend donc place dans le cadre des outils périphériques au langage SIDL.
Sugar étant un framework qui servira très probablement à réaliser des jeux vidéos, il est très probable que le code qui sera produit par les futurs utilisateurs sera très volumineux. Dans de telles circonstance il est indispensable de pouvoir disposer d'un générateur de documentation. On pourrait penser que documenter seulement le code C++ peut s'avérer suffisant, mais cela ne reflète rien du code SIDL l'ayant généré. Si l'on souhaite le reprendre, il s'avère très difficile à comprendre. De plus, comme expliqué plus haut, le code C++ généré ne montre plus les relations d'héritage car il s'en est affranchi. Une documentation générée au moyen de Doxygen se trouverait donc très certainement obsolète.

\paragraph{}C'est dans l'optique de répondre à ces différents inconvénients du langage SIDL qu'Atonce a décidé de se doter de l'outil Jam. Ce logiciel intégré à Sugar sera le générateur de documentation. Pour être plus précis, c'est l'outil permettant de visualiser et de naviguer dans la spécification qui aura été créée. Il est à noter que le nom \textit{Jam} signifiant jambon fut choisi en raison de son appartenance aux aliments composants le petit déjeuner, au même titre que Sugar, signifiant le sucre.

\paragraph{}Il faut aussi préciser que les outils périphériques, et donc le générateur de documentation, doivent se montrer très modernes afin de rendre justice au langage SIDL. Ce point va étre décrit plus tard, mais il est important de comprendre que la modernité, voir même l'aspect attractif, sont inhérents aux outils afférants au langage SIDL.

\subsubsection{Description approfondie du projet}

Nous allons ici décrire l'application Jam de façon un peu plus approfondie.

\paragraph{}L'outil Jam que nous devons réaliser n'est en rien un générateur de documentation. En effet, il a plus pour but de naviguer dans la documentation générée. La partie de Sugar qui correspond à la génération de documentation fut réalisé en parallèle lors du stage de Herve Descombe. pour comprendre les mécanismes de génération, il faut donc regarder son mémoire de stage.

\paragraph{}Malgré tout, un des buts essentiel de ce projet était de définir les normes permettant de réaliser la documentation. Il fallait en effet se doter d'un standard afin de relier l'outil de génération et l'outil de navigation (Jam). Ce navigateur avait pour prérogatives d'utiliser la technologie Flash/Flex. Plus précisemment, il devait prendre la forme d'une Application Internet Riche. C'est-à-dire une application FLash de bureau.

\paragraph{}Cet outil Jam doit donc en premier lieu permettre de naviguer dans la documentation d'un projet SIDL. Ce n'est pas lui qui la génère. Il serait plus un substitut aux navigateurs web. En effet, la plupart des documentations générées donnent des pages HTML. Ainsi, un utilisateur peut à loisir y naviguer. Or, il fallait ici employer des outils permettant un rendu graphique et ergonomique qu'une simple page HTML n'aurait pu fournir.

\paragraph{}Pour bien comprendre la place de Jam dans la documentation générée et dans Sugar, il est nécessaire de regarder le schéma suivant :

\newpage
\begin{center}
 \begin{figure}[h!]
 \includegraphics[height=250px,width=400px]{Images/Fonctionnement-Sugar.png}
 \caption{Fonctionnement de l'application}
 \label{fonctionnement-sugar}
 \end{figure}
\end{center}

Cela permet bien de voir que la commande \textit{gendoc} se contente de générer le fichier XML et le fichier \LaTeX. Ces deux fichiers représentent réellement la documentation. Jam n'est que le visionneur qui doit permettre de trouver l'information voulu efficacement.

Mais il reste important de bien définir les normes. Cela fera l'objet d'une partie entière. Comme on le voit, le XML est à Jam ce que le HTML est aux navigateurs internet.